In a traditional telephone network, ringback is typically an audible tone sequence presented to a caller to signal that the called party's phone is being alerted of the caller's incoming call to the called party. Upon hearing ringback, the caller may generally assume that the called party is receiving a corresponding, concurrent (or nearly concurrent) alert, such as an audible ringtone sequence. The ringback usually continues until either the called party (or a call-handling function, such an answering machine) answers the call or the caller hangs up before the call is answered.
The model for ringback has evolved similarly in both circuit-switched telephony with out-of-band signaling and services (Signaling System 7 (SS7) and Advanced Intelligent Network (AIN), for example), and packet-based telephony, such as Voice over Internet Protocol (VoIP).
Ringback tone in these types of systems is typically stored as an audio data file on a network entity, such as a network server, and played out to a caller's phone during call setup when the entity receives a signal, from a called switch for example, indicating that the called party's phone is being alerted.
The server-based model of ringback tone storage/playout can support multiple ringback tones, and lends itself to a variety of schemes for customization of ringback tones. An example of customization of ringback tone is a user feature that allows a subscriber in a carrier or service provider network to select one or more ringback tones that will be presented to callers to that user. The carrier or service provider may in turn charge a fee to the subscriber for access to the feature.
In recent years, basic techniques for setting up and connecting VoIP calls have also advanced substantially. As a general matter, a signaling protocol such as the well known Session Initiation Protocol (SIP) will be used to exchange signaling messages between calling and called parties, so as to set up a VoIP call between the parties. For instance, when the calling party dials the telephone number of a called party, the calling party's VoIP phone may generate and send over an IP network to the called party's phone a SIP “INVITE” message that requests setup of a media session between the phones. The SIP INVITE message designates the IP address of calling party's phone and describes one or more attributes of the desired session, such as voice coding scheme to be used and so forth.
Upon receipt of the SIP INVITE message, the called party's phone may then ring to alert the called party of the call. Possibly in response to the called party answering the call, the called party's phone may then generate and send over the IP network to the calling party's phone a SIP “200 OK” message that indicates acceptance of the requested session. The SIP 200 OK message similarly designates the IP address of the called party's phone and describes any alternative proposed attributes of the call session.
Upon receipt of the SIP 200 OK message, the calling party's phone then generates and sends to the called party's phone a SIP “ACK” message, which acknowledges setup of the session. The calling and called parties may then proceed to exchange packets representing voice or other bearer data in the agreed manner, i.e., the call may proceed.
One significant advance in this regard is the introduction of an enhanced proxy system now well known as the “IP Multimedia Subsystem” or “IMS.” With IMS, the IP network will include at least one “Call Session Control Function” (CSCF), which functions as an enhanced signaling proxy through which SIP signaling flows, and which can act upon or in response to the SIP signaling in order to provide or facilitate various services. One CSCF (referred to as a calling CSCF (O-CSCF) or a proxy CSCF (P-CSCF)), may serve a calling party, while another CSCF (referred to as a called CSCF (T-CSCF) or a serving CSCF (S-CSCF)), may serve a called party. Further, the network may include at least one “Home Subscriber Server” (HSS), which is a profile database that contains service profile data for various subscribers, such as data indicating for a particular call what services and service attributes apply to a given calling party and to a given called party. In addition, the network may include various application servers that are arranged to carry out special services or functions.
In practice, when a device sends a SIP INVITE message, the message will pass to a CSCF. The CSCF may then query the HSS to determine whether particular applications should be invoked, based on the profile of either or both parties to the SIP signaling exchange. According to this determination, the CSCF may then send the SIP INVITE to a particular application server (designated by the HSS for instance), and the application server may then operate on or in response to the SIP INVITE in some manner and send the SIP INVITE back to the CSCF, and the CSCF may then send the SIP INVITE along to its destination.
An example application of such IMS signaling is to facilitate pre-paid or other account balance tracking for VoIP calling. When a party seeks to set up a VoIP call by sending a SIP INVITE to a called party, a CSCF may shunt that SIP INVITE to an account balance server, and the account balance server may confirm (by reference to the HSS for instance) that the calling party has sufficient balance to proceed with the call and, if so, may pass the SIP INVITE back to the CSCF, and the CSCF may pass the SIP INVITE along to its destination. When SIP 200 OK and SIP ACK messages flow in turn between the calling and called parties, the CSCF may then further signal to the account balance server, to allow the account balance server to begin decrementing the calling party's account balance. And when the call ends (as a SIP “BYE” message flows from one party to the other, for instance), the CSCF may similarly signal to the account balance server, to allow the account balance server to stop decrementing the calling party's account balance and update the balance record accordingly. Many other examples of IMS signaling are possible as well.
In other situations, the CSCF itself may itself apply enhanced services when faced with SIP signaling, regardless of whether the CSCF also requests the assistance of an application server. For instance, when the CSCF receives a SIP INVITE destined to a particular party, the CSCF may query the HSS and thereby determine that the called party has a call-forwarding function set to indicate that calls to the called party should be forwarded to a designated third party. In response, the CSCF may then convert the SIP INVITE into a SIP 181 call-forwarding initiation message and send the SIP 181 message to the third party's device, instead of setting up the call to the originally called party. Upon receipt of such a message, the third party's device may then respond with a SIP 200 OK indicating acceptance of the forwarded call (possibly in response to a the third party answering the call), and that SIP 200 OK would flow through the CSCF to the calling party. In turn, the calling party may send a SIP ACK via the CSCF to the third party, so as to complete setup of the forwarded call, and the calling party and third party may begin communicating.
One additional function that can be carried out by a CSCF or other IMS elements (e.g., a Service Capability Interaction Management (SCIM) function) is to verify the availability of, and reserve, any access-network bandwidth necessary for a device to engage in a requested communication session (such as a VoIP session for instance). Where a party's device communicates via a cellular wireless network, for instance, the device may be served by a Packet Data Serving Node (PDSN) and a Radio Access Network (RAN). When session setup signaling passes through IMS, the CSCF, SCIM, or other IMS entity may further engage in signaling with the PDSN or RAN (or with a Policy Decision Function (PDF) that in turn communicates with a Policy Enforcement Point (PEP) such as the PDSN) to determine whether the bandwidth necessary for the requested session is available and, if so, to reserve the bandwidth.